home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / doc / www_talk.arc / 000384_bobw@csg.uwaterloo.ca _Mon Nov 23 16:01:33 1992.msg < prev    next >
Internet Message Format  |  1992-11-30  |  2KB
  1. Return-Path: <bobw@csg.uwaterloo.ca>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA14899; Mon, 23 Nov 92 16:01:33 MET
  4. Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
  5.     id AA13421; Mon, 23 Nov 92 16:13:26 +0100
  6. Received: by csg.uwaterloo.ca
  7.     id <AA20554>; Mon, 23 Nov 92 10:11:57 -0500
  8. From: Bob Wildfong <bobw@csg.uwaterloo.ca>
  9. Message-Id: <9211231511.AA20554@csg.uwaterloo.ca>
  10. Subject: Embedded graphics (was Re: Book metaphor)
  11. To: dsr@hplb.hpl.hp.com (Dave_Raggett)
  12. Date: Mon, 23 Nov 92 10:11:56 EST
  13. Cc: www-talk@nxoc01.cern.ch
  14. In-Reply-To: <9211231123.AA12237@manuel.hpl.hp.com>; from "Dave_Raggett" at Nov 23, 92 11:23 am
  15. X-Mailer: ELM [version 2.3 PL11]
  16.  
  17. > 
  18. > Pictures
  19. > ========
  20.  
  21. > It seems sensible to support a variety of formats: TIFF, GIFF, DIBs
  22. > Fax group III/IV, CGM etc. The idea of embedded objects which return their
  23. > size and can display themselves at a given location seems appropriate.
  24. > 
  25. > The client doesn't know in advance about these embedded objects, it therefore
  26. > makes sense for the server to be able to append them to the requested html
  27. > document so as to avoid a further network loop delay for retrieving them.
  28. > 
  29. > Dave Raggett
  30. > 
  31. > HP Labs, Bristol, UK.   (dsr@hplb.hpl.hp.com)  +44 272 228046
  32.  
  33.  
  34. I've been through this line of thought in a hypertext/electronic book project.
  35. Yes, it's more efficient to include the graphics in the HTML data stream, but
  36. only if you just have one version (format) for each graphic.
  37.  
  38. We found it best in the long run to provide our embedded graphics in several
  39. formats, and allow the client to choose the format most appropriate for its
  40. output device (e.g. 8-bit vs 24-bit colour, Postscript if the device supports
  41. it, WMF if the client is running the Microsoft Windows version of the viewer
  42. program, etc).
  43.  
  44. The server sends a list of available formats and the client requests the
  45. graphic file that it prefers.  This permits the best available graphic quality
  46. on each of several possible output devices, but imposes an extra network delay.
  47. Still, graphic files tend to be pretty big, so the extra delay is only a few
  48. % of the file's download time.
  49.  
  50.  
  51. Bob Wildfong                                       bobw@csg.uwaterloo.ca
  52. Waterloo, Ontario                                  bobw@csg.waterloo.edu
  53. #include <stddisclaimer.h>
  54.